SSH is a protocol that leverages public key cryptography to authenticate and secure access among computers in a computer network. SSH secures Telnet-related operations. Telnet has traditionally been used for remote management of Unix, Linux, and Unix-like computers, routers, switches, firewalls, and other appliances and systems. It has also been used for automated connections between systems via scripting and batch processing. SSH Devices include SSH clients, SSH servers, and SSH-enabled computing appliances, entities, or virtual machines acting as SSH clients or SSH servers. Separate user accounts may also act as SSH Devices.
However, Telnet does not provide for the authentication of systems or the encryption of connections (for example, usernames and passwords are passed across a Telnet connection in clear text and can be intercepted by someone listening on the network). SSH secures Telnet connections by authenticating servers to which a user or system are connecting (ensuring they are not providing their username and password to the wrong system), encrypting the connection to the server (so that usernames and passwords are not intercepted), and optionally authenticating the client using public key cryptography as an alternative to usernames and passwords. File transfer protocol (FTP) has commonly been used along with Telnet to facilitate and is subject to the same security challenges. Consequently, protocols such as Secure FTP (SFTP) and Secure Copy (SCP) have been developed to be used alongside SSH and generally use the same public and private keys (Key Pairs) used for SSH for their security. References within this document to SSH also refer to SFTP and SCP.
In the SSH protocol, there is a client (the system or user that initiates the connection) and a server (the system to which a connection is requested and made). In the simplest configuration, a Key Pair is generated for an SSH server. The public key is used by one or more SSH clients to authenticate the SSH server. The SSH clients store the public key after the first connection with the SSH server, creating a trusted relationship known in which the stored key is known as a Known Host Key. Optionally, a Key Pair can be generated for an SSH client to authenticate the client to SSH servers using public key cryptography instead of usernames and passwords. The SSH servers to which the SSH client connects may store its public key, creating a trusted relationship in which the stored key is known as an Authorized Key.
Because administrators who manage the systems that act as SSH servers and clients can individually generate Key Pairs and distribute or store the public keys used for authentication, these Key Pairs and public keys have proliferated broadly in organizations. This phenomenon has effectively created untracked trusted relationships and access between systems (and users).
SSH is used in large network environments where thousands or tens of thousands of users, computers, and connected devices rely on it for secure authentication for mission critical applications. The resulting number of public and private keys used for authentication grows geometrically with the expansion of the network environment. Moreover, computing networks are not static. Users and devices are added, removed, change on a regular basis; authentication rights of users and devices are also modified regularly to correlate with organizational changes. Security policies of the organization maintaining the network environment may also be altered. Thus, the management of public-private key pairs in an SSH environment (SSH Key Pairs) is critical to establishing and maintaining security within the organization's network environment
There are five primary challenges that have emerged through the use and proliferation of SSH under the current state of the art. They include:
(1) No Inventory of SSH Key Pairs: Because administrators of a network computing environment are able to easily create and deploy SSH Key Pairs themselves, most organizations do not have a central inventory of them. They are consequently not able to monitor entitlements, whether proper key lengths are being used, whether weak-key formats remain in use (e.g. RSA1), or whether Key Pairs are regularly replaced, as is considered essential for a secure system. This creates a major security risk because SSH is the most commonly used method for root-level login to mission critical systems.
(2) Unaccounted for Known Host and Authorized Keys: Public keys stored and used by clients to authenticate servers (Known Host Keys) or by servers to authenticate clients (Authorized Keys) must be tracked because they represent explicit trust between and access to systems. If the wrong Known Host Key or Authorized Key is in place, an SSH system may unintentionally establish a connection with the wrong system or user, thus enabling a security breach. Most organizations have no inventory of their Known Host Keys or Authorized Keys. Consequently, mission critical servers may be trusting Public Keys assigned to systems or users that should not have been or should no longer be trusted. A prime example is the inadvertent continued validity of keys for individuals who have been re-assigned within, or terminated by, the organization maintaining the network environment.
(3) No Key Replacement: Best practices for secure management of authentication credentials dictate that cryptographic keys should be changed regularly to reduce the likelihood that an unauthorized person has gained access to a key and is able to intercept confidential communications or impersonate a person or system and perform unauthorized operations or gain unauthorized data access. Most organizations rarely, if ever, replace their SSH Key Pairs, even though system administrators with access to those Key Pairs may have been reassigned or terminated. Due to the mission critical nature of the systems where SSH is used, this creates a significant risk that an unauthorized user or system can access sensitive information or systems.
(4) Failed Key Replacement: In order to replace a Key Pair, all of its corresponding Known Host Keys or Authorized Keys must also be replaced prior to the replacement of the Key Pair. If a Key Pair is being used for automated batch operations (a very common practice) and all locations of the corresponding Authorized Keys and Known Host Keys are not properly updated when the Key Pair is replaced, it is likely that a mission critical system or process will fail because the new Key Pair will not be trusted. This is a likely scenario because organizations don't have accurate inventories of SSH Key Pairs and corresponding Authorized and Known Host Keys.
(5) Use of Weak Encryption Keys: The US National Institute of Standards (NIST) has recommended that organizations cease using cryptographic key pairs that are less than 2048-bits (256 bytes) in length due to the increased risk of factoring or brute-force attacks possible with smaller keys sizes. Many organizations continue using 1024-bit, 768-bit, and even 512-bit keys in their SSH environments because administrators are unaware of the risks rarely update Key Pairs, because tools to manage these vulnerabilities are not readily available, or because of the risk of a failed key replacement due to an incomplete inventory. This opens organizations to potential security breaches due to via a key factoring or brute force attack.
Thus, there is a clear need for an integrated system capable of addressing the shortcomings of the current practices prevalent for this important security mechanism. The system described provides such an integrated method and tool set, meeting the long-felt need for effective management of SSH Keys.